A type-passing implementation of value types and genericity

classes cannot be instantiated, but can be extended by any kind of class. They can extend only other abstract classes. There is a distinguished abstract class called Object which is the ultimate superclass of any other class. A class containing abstract methods, either declared or inherited, must itself be declared abstract. Reference classes are similar to traditional Java classes: their instances are allocated on the heap, and are manipulated indirectly via pointers. Objects of a reference class can be aliased, as there may be several pointers to the same object. The superclass of a reference class must be either another reference class or an abstract class. Value class instances are manipulated directly and cannot be aliased. A value class can extend only abstract classes or other value classes. Value classes are the only kind of value types in Pluto — Chapter 4 gives more detail on these, including some restrictions on subclasses of value classes. An object whose type is a value class is immutable: its instance fields cannot be updated once created. Section 4.1.2 explains the rationale for this decision. Reference and value classes may be declared final, to indicate that they cannot have subclasses. The arrangement of the different kinds in the class hierarchy is shown in Figure 3.1. The restriction on abstract classes extending only other abstract classes keeps the type system simpler, but it could be loosened to allow abstract classes to extend value and reference classes. However, the type system would then need to ensure that a reference class does not extend a value class indirectly via an Chapter 3. The basic Pluto language and compiler 33 intermediate abstract class. Otherwise there could be confusing behaviour caused by the different semantics of value-based and reference-based types. See Chapter 4 for details about the support for value-based types in Pluto. • Fields, value parameters and local variables always refer to a distinct object for reference types — there is no null or missing value. Local variables can be declared mutable, but cannot be used until they have been assigned a value at least once. • Classes, interfaces and methods support multiple type parameters, which can be bounded. Chapter 5 covers the design and implementation of genericity in more detail. • In the class hierarchy, method signatures can be varied when overridden: return types can be specialised and parameters can be generalised, in accordance with the variance rules covered in Section 2.7. This ability is not supported for multiple inheritance of method signatures through interface types. Whenever a method of some name is inherited through more than one supertype, the signatures must match exactly. The reason for this restriction is covered in Section 6.4.2. Figure 3.2 lists a simple but complete Pluto program. The point class shows the use of symbolic method names. It defines a method called == with one parameter, and a method called $ with no parameters. These methods can be called using infix and prefix expressions, respectively. Given a point object, say p, the prefix expression $p invokes the $ method of the p object. Similarly, an infix expression such as p == p invokes the == method of the p object, with itself as the single argument. The code within the methods of the point class also shows use of this syntax, as it invokes the == and $ methods that are defined by the int class. The transcript in Figure 3.3 shows a typical build session, where the Pluto source in file example.pto is compiled into C code by the first command, then the C compiler and linker is invoked to build an executable. 3.3 Compiler structure The overall design of the Pluto compiler is shown in Figure 3.4, which lists the different data structures used at each stage of compilation, together with the transformations applied at each pass. 3.3.1 Implementation language The Pluto compiler is written in Java[49], which proved useful in the development of a complex piece of software such as a compiler. For the purpose of this experimental work, speed of execution was not especially important compared to correctness and ease of development. The addition of genericity to Java (in particular for collection data structures) would have improved the clarity of the compiler code, and reduced development time. It would be straightforward to rewrite the compiler in the Pluto language itself, provided some form of file reading and writing capability were added to the standard library. The Java 2 Platform standard libraries contain a rich set of classes for building a graphical user interface, such as the AWT and Swing packages. In particular, the Swing JTree Chapter 3. The basic Pluto language and compiler 34 final value class point(x:int, y:int) { field x : int = x; field y : int = y; method ==(other:point) : boolean { return this.x == other.x && this.y == other.y; } method $() : String { return “[” + $this.x + “,” + $this.y + “]”; } static field origin : point = new point(0, 0); } abstract class Shape(pos:point) { field position : point = pos; abstract method draw(); }class Shape(pos:point) { field position : point = pos; abstract method draw(); } class Circle(centre:point, rad:int) extends Shape(centre) { field radius : int = rad; method draw() { String.println(“A circle at ” + $this.position + “ with radius: ” + $this.radius); } } abstract class Main() { static method run() : int { let s : Shape = new Circle(point.origin, 4); s.draw(); return 0; } }class Main() { static method run() : int { let s : Shape = new Circle(point.origin, 4); s.draw(); return 0; } } Figure 3.2: Example Pluto program % java pluto.Main example.pto % gcc pto_src*.c -lpluto -o example % ./example A circle at [0,0] with radius: 4 Figure 3.3: Example build process and output Chapter 3. The basic Pluto language and compiler 35 component allows a tree or graph structure to be examined using an intuitive graphical browser. It proved simple to add the necessary code to the Pluto compiler so that the abstract syntax tree, core tree and C level intermediate representation could be viewed using JTrees. This facility was of great use in locating errors in the compiler itself, by visual inspection of the intermediate representation of each stage.